I took a few more attempts at this, seems like it's now failing because it now needs both the .NET 10 and .NET 6 SDKs. Happy to keep attempting fixes on this if retargeting Expecto to .NET Standard 2.0 will be approved in principle.

closes #524

I think targeting netstandard2.0 would make sense, but I at least want to ask the person who changed it why they did so. I poked around and the change seems to have been @ratsclub

@ratsclub Do you remember why expecto moved from netstandard2.0 to net6.0?

I think good faith efforts have been made to understand previous changes and no clear reason has been uncovered.

I'd be comfortable going forward with returning Expecto to netstandard2.0.

I changed test projects to dual target net10.0 and net481 on Windows only. build.fsx was changed to a build project as this seems to work better when not using .NET SDK 6.

paket.lock rolled forward a lot of dependencies automatically when changing tfm. Not sure if they should all be pinned in the default group?

fwiw I still want to try looking at #498 again at some point (I keep failing to get time for it, but have an upcoming need for some AOT builds of things at work), and as you need to target .NET 8.0+ to get proper support for NativeAOT I might ask about multi-targetting things at .NET 8.0 and .NET Standard 2.0, rather than only .NET Standard?
(It could be changed later, but maybe it's easier to do it in one go?)

I can give it a go tomorrow but should be trivial to add the target. Not sure about AOT the big challenge will be F# uses reflection based string printing by default

@Numpsy I'd be curious to learn more about your AOT requirements sometime.

I've been digging into improved code location, and it looks like our main option there is heavily reflection-based.

Not sure about AOT the big challenge will be F# uses reflection based string printing by default

Yes, the %A stuff is potentially a problem (I do have a cli tool I'm working on at work largely working with an AOT build though)

I'd be curious to learn more about your AOT requirements sometime.

I started looking at it was back and then stopped because my main task at the time was AOT builds of a CLI app where the integration tests are a separate process and don't need to be AOT themselves, and then I started thinking that an AOT build of just a library built for native use should be tested with a native test framework of some sort, but then I now have a case where it would be useful if I could build an existing Expecto test executable natively.. so, I'll give it another try at least.

I've been digging into improved code location

'All' I'd be wanting to do is natively compile and run a test exe - no test explorers or code locations - so hopefully that part isn't a problem.

@farlee2121 It has been a while since I did that change. I remember that it was related to not being able to use Tasks properly when targetting netstandard2.0 alone.

That's great context. We'll have to be extra mindful to review task behavior. Thanks!

Is there anything left blocking this one? I think it's ready now with or without the dual targeting to net8.0

I didn't realize you'd finished the work. I'll try to review it soon

@roboz0r The changes mostly made sense to me. I left a few questions.

I've been thinking of migrating fake off of fsx for a while, so thanks for doing that too.

I've been thinking of migrating fake off of fsx for a while, so thanks for doing that too.

Does fake-cli still need to be in the tools json if the build script has been converted into a project?

I've been thinking of migrating fake off of fsx for a while, so thanks for doing that too.

Does fake-cli still need to be in the tools json if the build script has been converted into a project?

Good point. I don't think we need fake-cli anymore.

I got impatient because this will help with another feature I'm working on.

The only question I didn't resolve is why System.Runtime.CompilerServices.Unsafe was included. It didn't appear to be doing anything. @roboz0r What was this package include meant to accomplish?

Thanks for the review and getting the PR cleaned up. On System.Runtime.CompilerServices.Unsafe I don't recall any specific reason I wanted it. Most likely I was chasing warnings about transitive deps and just added it.